NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/223

Internet Message Format | 1996-08-06 | 4.6 KB

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: Integral conversion e.t.c. (was: Re: Hungarian notation)
Date: Tue, 30 Jan 96 00:13:24 GMT
Organization: none
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <[e-mail]>
           [e-mail] "James Kanze US/ESC 60/3/141 #40763" writes:

>Again, I think that one should make the distinction (at least in
>comp.lang.c) between undefined undefined by the standard, and really
>undefined.

I don't think you'll find it easy to make such a distinction.

  The distinction is not defined in the standard, but is
>very present in real life.  Thus, dereferencing a NULL pointer is
>undefined, and while an implementation is free to define it if it
>likes, in practice, none will define it to do anything good.  Adding a
>third parameter to main is also undefined according to the C standard,
>but most Unix compilers (and maybe others) do define it in a very
>useful way; as far as I know, Posix may even define it so.

Frankly the 3rd parameter is to be avoided these days - treat it the
same as void main. POSIX doesn't support it; the correct POSIX way
is to use the extern char **environ variable.

>Although I find it hard to explain precisely the difference,

Historical usage.

>I would
>generally consider counting on implementation defined behavior in
>derefencing the null pointer bad practice.  On the other hand, using
>the added parameter to main wouldn't particularly bother me,
>especially if, as is the case in most of my applications, the program
>is intimely bound to Unix anyway.

That is the same argument as a DOS programmer using void main(). In both
cases the fix is trivial and should be done to uphold the general
principle that if there is a viable portable way of doing something, use
it. OK, using environ doesn't make the program generally portable across
ANSI platforms but it is still more portable (meets more standards giving
you a higher level of guarantee) than the 3 parameter main.

>This is always a delicate line.  A Windows program using far and near
>pointers: I don't believe they can avoid it, and the program surely
>won't run on anyother platform without major modifications.  A filter
>program invoked from the DOS command line: I'd consider the use of far
>and near a major flaw, and would heartily condemn a design which
>required it.

That doesn't violate the principle of coding portably where it is viable.
It just may not always be viable.

>I agree, but...
>
>Try naming a global function read, and see what happens (on most
>compilers, anyway).  In fact, the Posix standard requires it, and
>thus, you cannot be Posix compliant without encroaching upon the user
>name space.  (For example.  I'm sure that most other systems will have
>similar constraints.)

Yes, but that namespace need only be encroached upon if you include
POSIX (rather than ANSI) specific header files. As soon as you do that you
invoke undefined behaviour according to the C standard hence the
implementation is free to follow the POSIX rules. The other issue is
identifiers with external linkage. If the system doesn't link an identifier
*defined* by the program to the system library (common linker behaviour)
this needn't be a problem.

The same principle can be applied to near/far under DOS compilers. A
strictly conforming implementation can implement them if they are only
activated on the inclusion of a non-ANSI header file.

>Well, I'm not sure that I'd consider Posix a fossil of an era long
>past, although it certainly reflects a long history.
>
>I'm not sure where to draw the line.  Discussions of `read' certainly
>don't belong in c.l.c.  But simply telling someone that his system is
>broken because printf stopped working when he declared a global read
>is not going to help anyone, even if, strictly speaking, it is true
>according to the standard.

The point is that even on a POSIX system such a program should work
unless the program includes something like unistd.h. At that point
the behaviour of the program is no longer defined by the ANSI standard,
so doesn't prevent the system being ANSI conformant.

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------